[raster] By default, ST_Tile() should no longer pad tiles with NODATA

[pracine]

So we can tile rasters which width and height do not have a common divisor without increasing the size of the coverage. Ex. width=1591 and height=1446

padwithnodata should default to FALSE

We also need a nodatavalue parameter for the case where padwithnodata is true and the rasters do not have a nodata value defined.

[dustymugs]

So, "paddwithnodata" = FALSE would create a tile whose dimensions aren't the same as the other tiles (regularly blocked = FALSE)

[pracine]

Replying to dustymugs:

So, "paddwithnodata" = FALSE would create a tile whose dimensions aren't the same as the other tiles (regularly blocked = FALSE)

Correct.

[dustymugs]

This would be as part of the changes described in #2122.

[pracine]

Hum. I don't really agree with the change in name as it makes the following description lose its meaning.

I would further say that the original description is actually what make things working with #2122: Padding should become optional.

[dustymugs]

From the description:

 So we can tile rasters which width and height do not have a common divisor without increasing the size of the coverage. Ex. width=1591 and height=1446

I don't see the problem with doing away with padding in the first place. Why take extra space and fill in NODATA (or min possible value) when the spec has an exemption in it? Based upon your specs…

This constraint ensures that all tile are of the same size and hence, do not overlap and do not leave gaps in the coverage. The exceptions for right-most and bottom tiles are to ensure that the coverage conserve the same extent as the original loaded raster. Reading applications have to check for the width and height of rasters (or tiles) before blindly copy their data into buffers having their sizes determined by blocksize_x and blocksize_y.

It doesn't look it it matters to be padded in the database anymore. It's the client's responsibility to handle the possibility that edge tiles can have smaller dimensions.

[pracine]

Totally agree. My point is more in the direction provided in #826. But since the code is not already written for this function we can wait someone ask for it.

So you can just make it not padding for now.

[dustymugs]

Padding is useless now. If anything, the complaints typically involve, "Why is my exported raster of different size than my source raster?". Eliminating padding will get rid of that question.

[dustymugs]

Since I added a padding option to raster2pgsql, the parameters "padwithnodata" and "nodatavalue" can come back in.

[dustymugs]

Added in r10836